Publish/subscribe messaging is a form of asynchronous computer network messaging where publishers post messages and subscribers specify categories of messages they want to receive. Publish/subscribe messaging systems utilize message brokers to filter the messages and forward them to the subscribers.
One example of an existing publish/subscribe messaging system consists of a fully interconnected collective where groups of message brokers forward messages from publishers to subscribers within that collective. The subscribers register a subscription with a message broker and the message broker registers a matching subscription with neighboring message brokers. The matching subscription is referred to as a proxy-subscription. This proxy-subscription allows the message broker to forward messages to other message brokers that attach to a subscriber.
Another example of an existing publish/subscribe messaging system is a hierarchy. A publish/subscribe hierarchy consists of parent/child relationships between the message brokers but without the loop of a fully interconnected system. When a “parent” message broker receives a message from a publisher, that parent forwards the message to each of its “child” message brokers. Each child then forwards the message on to each of its child brokers and to any subscribers of that message type that are connected to that child. One limitation of a publish/subscribe hierarchy is that looping messages are not prevented by the architecture alone. Messages may pass through an arbitrary number of message brokers before reaching a subscriber if there is an error in the configuration.
Existing publish/subscribe messaging systems can be constructed as a hub and spoke network with a collective of message brokers, commonly referred to as hubs, at the hub collective and a set of child spokes, wherein each child treats a fixed member of the hub collective as its parent. The scalability of the hub collective is increased over this form of hierarchy by allowing multiple systems to operate as a hub.
When publish/subscribe systems are grouped together in a collective and share proxy-subscriptions, any publishing hub has to forward the message to all subscribing hubs. If there are a large number of subscribers, then the load that this requirement imposes on the publishing hub will limit the scalability of the collective.
What is needed is a publish/subscribe messaging system that allows for greater scalability by balancing the load and greater availability by eliminating the single hub as the single point of failure.